Bump wasm-cxx-shim to v0.4.0-alpha.1, drop wasm-uu ray_cast cfg-gates#40
Merged
Conversation
zmerlynn
force-pushed
the
shim-0.4-alpha-drop-raycast-gates
branch
from
b32da31 to
aa0b982
Compare
The shim's v0.4.0-alpha.1 release moves its tested manifold pin to
upstream main HEAD (`5f95a3ac`), the same commit our host build pins.
That means the wasm-uu lane now sees the same C API surface as host —
including ray_cast, which we cfg-gated off in 0.1.7 / 3.4.106 because
the previous shim (v0.3.0) defaulted to the v3.4.1 pin and didn't
have it. The gates can drop now.
The shim is alpha because it carries a single vendored diff of
upstream manifold#1690 (the PR that adds `MANIFOLD_NO_IOSTREAM`
natively). When #1690 merges, the shim re-cuts as non-alpha v0.4.0
and the carry-patch goes away. The alpha pin SHA is encoded in the
tag itself (`v0.4.0-alpha.1+5f95a3ac`) for explicit lockstep.
Changes:
- `crates/manifold-csg-sys/build.rs`: WASM_CXX_SHIM_TAG → `v0.4.0-alpha.1+5f95a3ac`.
- Drop the `#[cfg(not(all(target_arch = "wasm32", target_os = "unknown")))]`
gates introduced in 0.1.7 / 3.4.106:
- sys: `ManifoldRayHitVec`, `ManifoldRayHit`, `manifold_ray_hit_vec_size`,
`manifold_alloc_ray_hit_vec`, `manifold_destruct_ray_hit_vec`,
`manifold_delete_ray_hit_vec`, `manifold_ray_cast`,
`manifold_ray_hit_vec_length`, `manifold_ray_hit_vec_get`
- safe: `pub mod ray`, `pub use ray::RayHit`, `Manifold::ray_cast`
- tests: `ray_cast_through_cube`, `ray_cast_miss`, `ray_cast_hit_has_normal`
- `wasm32-uu/CMakeLists.txt`: comment updated.
- `CLAUDE.md`: "Pin / shim follow-ups" updated to note ray_cast is no
longer gated.
- `.claude/skills/deep-review/SKILL.md`: matching update in section 10.
- `docs/plans/wasm-unknown-unknown.md`: shim version bumped.
Versions for the next release:
manifold-csg-sys 3.4.106 → 3.4.107
manifold-csg 0.1.7 → 0.1.8
manifold3d-sys / manifold3d facades follow lockstep `=` pins.
Verified:
- 214 host integration tests pass (3 ray_cast tests run on host as
always)
- wasm-uu CI-equivalent build clean: cargo build --target
wasm32-unknown-unknown -p manifold-csg --no-default-features
--features unstable-wasm-uu --tests --examples
- Produced wasm has zero unexpected imports (`wasm-objdump -x -j Import`
reports "Section not found") — confirms ray_cast now resolves against
the helper-built manifold archive
- 12 playground Node tests pass against the new build
- cargo fmt + cargo clippy clean
Followup: when shim's non-alpha v0.4.0 ships (after #1690 merges), bump
the pin off `-alpha.1`. No code changes expected — just a tag swap.
zmerlynn
force-pushed
the
shim-0.4-alpha-drop-raycast-gates
branch
from
aa0b982 to
dc62020
Compare
4 tasks
zmerlynn
added a commit
that referenced
this pull request
May 3, 2026
Binds the upstream `ManifoldExecutionContext` C API surface added in manifold's master post-v3.4.1 (`5f95a3a`) and now natively supported in the wasm-uu lane via shim v0.4.0-alpha.1 (PR #40). Why it matters: manifold operations are lazy. Building a CSG tree is cheap; the actual evaluation runs when something queries the result (num_tri, mesh extraction, status). For nontrivial trees this can be seconds to minutes, and there was previously no way to cooperatively abort it. ExecutionContext fixes that — pass it to a new `status_with_context` method and another thread can `cancel()` it. Use case examples: - Web demos / interactive UIs: cancel a stale boolean when the user changes inputs. - Server-side: timeout long-running ops without dropping the worker. - Batch processing: progress observation for status reporting. C API surface added (10 items in manifold-csg-sys): - `ManifoldExecutionContext` opaque type - 4 lifecycle: `_size`, `_alloc`, `_destruct`, `_delete` - 1 constructor: `manifold_execution_context(mem)` - 3 control: `_cancel`, `_cancelled`, `_progress` - 1 cancellable trigger: `manifold_status_with_context` Safe wrapper (manifold-csg): - New `execution` module with `ExecutionContext` struct (`Send + Sync`, justified by upstream's "safe to read/write from any thread" guarantee in the C header). - Methods: `new()`, `cancel()`, `is_cancelled()`, `progress()`, `Drop`. - `Manifold::status_with_context(&self, &ExecutionContext) -> ManifoldError` for the cancellable evaluation trigger. - 5 integration tests: initial state, sticky cancel, cross-thread cancel via Arc, status_with_context happy path, status_with_context with already-cancelled context. - API_COVERAGE.md updated with a new "Execution Context" section. Verified end-to-end: - 219 host integration tests pass (was 214; +5 new ExecutionContext) - wasm-uu CI-equivalent build clean; produced wasm has zero unexpected imports (confirms ExecutionContext links cleanly through the shim's v0.4.0-alpha.1 helper) - cargo fmt + cargo clippy clean Versions stay at 0.1.8 / 3.4.107 (pre-bumped by #40, this addition is additive so the bump still covers it).
zmerlynn
added a commit
that referenced
this pull request
May 3, 2026
…41) Binds the upstream `ManifoldExecutionContext` C API surface added in manifold's master post-v3.4.1 (`5f95a3a`) and now natively supported in the wasm-uu lane via shim v0.4.0-alpha.1 (PR #40). Why it matters: manifold operations are lazy. Building a CSG tree is cheap; the actual evaluation runs when something queries the result (num_tri, mesh extraction, status). For nontrivial trees this can be seconds to minutes, and there was previously no way to cooperatively abort it. ExecutionContext fixes that — pass it to a new `status_with_context` method and another thread can `cancel()` it. Use case examples: - Web demos / interactive UIs: cancel a stale boolean when the user changes inputs. - Server-side: timeout long-running ops without dropping the worker. - Batch processing: progress observation for status reporting. C API surface added (10 items in manifold-csg-sys): - `ManifoldExecutionContext` opaque type - 4 lifecycle: `_size`, `_alloc`, `_destruct`, `_delete` - 1 constructor: `manifold_execution_context(mem)` - 3 control: `_cancel`, `_cancelled`, `_progress` - 1 cancellable trigger: `manifold_status_with_context` Safe wrapper (manifold-csg): - New `execution` module with `ExecutionContext` struct (`Send + Sync`, justified by upstream's "safe to read/write from any thread" guarantee in the C header). - Methods: `new()`, `cancel()`, `is_cancelled()`, `progress()`, `Drop`. - `Manifold::status_with_context(&self, &ExecutionContext) -> ManifoldError` for the cancellable evaluation trigger. - 5 integration tests: initial state, sticky cancel, cross-thread cancel via Arc, status_with_context happy path, status_with_context with already-cancelled context. - API_COVERAGE.md updated with a new "Execution Context" section. Verified end-to-end: - 219 host integration tests pass (was 214; +5 new ExecutionContext) - wasm-uu CI-equivalent build clean; produced wasm has zero unexpected imports (confirms ExecutionContext links cleanly through the shim's v0.4.0-alpha.1 helper) - cargo fmt + cargo clippy clean Versions stay at 0.1.8 / 3.4.107 (pre-bumped by #40, this addition is additive so the bump still covers it).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The shim's v0.4.0-alpha.1 release moves its tested manifold pin to upstream main HEAD (`5f95a3ac`), the same commit our host build pins. That means the wasm-uu lane now sees the same C API surface as host — including ray_cast, which we cfg-gated off in 0.1.7 / 3.4.106 because the previous shim (v0.3.0) defaulted to v3.4.1 and didn't have it. The gates can drop now, exactly the followup the previous release's CLAUDE.md noted.
The shim is alpha because it carries a single vendored diff of upstream manifold#1690 (the PR that adds `MANIFOLD_NO_IOSTREAM` natively). When #1690 merges, the shim re-cuts as non-alpha v0.4.0 and the carry-patch goes away. The alpha pin SHA is encoded in the tag itself (`v0.4.0-alpha.1+5f95a3ac`) for explicit lockstep.
Net diff: +23 / -48 across 14 files. Almost all of it is removing cfg-gate annotations.
What dropped
cfg-gate removals (
#[cfg(not(all(target_arch = "wasm32", target_os = "unknown")))]):A grep for `target_os = "unknown"` now only turns up the OBJ I/O gates, which stay (they're gated for a different reason — iostream patches strip OBJ I/O regardless of pin).
Versions (pre-bumped for next release)
Followup
When the shim's non-alpha v0.4.0 ships (after upstream #1690 merges), bump the pin off `-alpha.1`. No code changes expected — just a tag swap.
Test plan